Integration heterogener Produktdaten in verteilten, komplexen Entwicklungsprozessen

Moderne Produkte, wie etwa Automobile oder Maschinen, werden infolge der zunehmenden Digitalisierung komplexer. Neben mechanischen Bauteilen umfassen sie zahlreiche mechatronische,elektronische und elektrische Bauteile. Um unterschiedliche Kundenbedürfnisse, länderspezifische Charakteristika oder gesetzliche Anforderungen bedienen zu können, muss für diese Produkte eine hohe Variabilität ermöglicht werden. Die Produktentwicklung erfolgt üblicherweise system- und komponentenorientiert und wird mit Methoden des Concurrent Engineering realisiert. Unterschiedliche Anforderungen und Aufgaben der Produktentwickler führen zu einer autonomen, heterogenen IT-Systemlandschaft, die sowohl aus etablierten Informationssystemen, etwa Produktdatenmanagement-Systemen, aber auch aus fachbereichsspezifischen Lösungen besteht. Während zwischen den etablierten Informationssystemen häufig Austauschschnittstellen existieren, erfolgt der Abgleich von Produktdaten aus diesen Systemen mit fachbereichsspezifischen Lösungen häufig manuell oder gar nicht. Zusätzlich ist die IT-Systemlandschaft der Produktentwicklung einem ständigem Wandel unterworfen, so dass Austauschschnittstellen kontinuierlich angepasst und erweitert werden müssen. Während die unabhängige Entwicklung von Systemen und Komponenten die Entwicklungszeit reduziert, wird es zu verschiedenen Zeitpunkten während der Produktentwicklung notwendig,die autonomen, heterogenen Produktdaten zu synchronisieren. Fehlerhafte und inkonsistente Produktdaten in späten Entwicklungsphasen führen zu erheblichen Kosten, so dass die Kontrolle der Vollständigkeit und Konsistenz von Produktdaten möglichst früh sichergestellt werden sollte, um eine hohe Produktqualität zu gewährleisten. Gegenstand dieser Arbeit ist das PROactive Consistency for E/E product Data management(PROCEED)-Framework, das die Integration autonomer, heterogener Produktdaten ermöglicht. PROCEED unterstützt den gesamten Lebenszyklus der Integration von Produktdaten, beginnend mit der initialen Integration, über die Steuerung und Überwachung des Integrationsprozesses sowie die Unterstützung von Schema- und Datenänderungen. Um die strukturelle Heterogenität von Produktdaten zu überwinden, werden Informationssysteme in sog. Produktontologien abstrahiert. Die Produktontologien werden anschließend mit Hilfe von Abbildungsregeln und -aktionen in eine gemeinsame Sicht überführt. Auf Basis dieses Modells werden Qualitätsmetriken der Integration, wie z.B. die Konsistenz und Vollständigkeit definiert. Zusätzlich wird das dynamische Verhalten bei Änderungen von Schema und Daten der Produktontologien erläutert. Schließlich wir das PROCEED-Rahmenwerk prototypisch realisiert und in einer Fallstudie angewandt

On the Integration of Electrical/Electronic Product Data in the Automotive Domain

The recent innovation of modern cars has mainly been driven by the development of new as well as the continuous improvement of existing electrical and electronic (E/E) components, including sensors, actuators, and electronic control units. This trend has been accompanied by an increasing complexity of E/E components and their numerous interdependencies. In addition, external impact factors (e.g., changes of regulations, product innovations) demand for more sophisticated E/E product data management (E/E-PDM). Since E/E product data is usually scattered over a large number of distributed, heterogeneous IT systems, application-spanning use cases are difficult to realize (e.g., ensuring the consistency of artifacts corresponding to different development phases, plausibility of logical connections between electronic control units). To tackle this challenge, the partial integration of E/E product data as well as corresponding schemas becomes necessary. This paper presents the properties of a typical IT system landscape related to E/E-PDM, reveals challenges emerging in this context, and elicits requirements for E/E-PDM. Based on this, insights into our framework, which targets at the partial integration of E/E product data, are given. Such an integration will foster E/E product data integration and hence contribute to an improved E/E product quality

Managing Complex Data for Electrical/Electronic Components: Challenges and Requirements

In the automotive domain, innovation is driven by the introduction and continuous improvement of electrical and electronic (E/E) components (e.g. sensors, actuators, and electronic control units). This trend is accompanied by increasing complexity and interdependencies between them. In addition, external impact factors (e.g. changes of regulations) demand for management of E/E product data (E/E-PDM). Since E/E product data is scattered over distributed heterogeneous IT systems, application-spanning use cases (e.g. consistency of artifacts, plausibility of logical connections between electronic control units) are difficult to realize. Consequently, the partial integration of the corresponding application data models becomes necessary. Changes of application data models are common in context of E/E-PDM, but they are not considered by existing application integration approaches. Furthermore, no methodology for creating application integration models exists. This paper elaborates challenges to be tackled when integrating applications containing E/E product data. It further presents properties of the IT landscape involved in E/E-PDM and reveals occurring problems. Finally, requirements for E/E-PDM are discussed

Towards Flexible Process Support on Mobile Devices

Ubiquitous computing is considered as enabler for linking everyday life with information and communication technology. However, developing pervasive and mobile applications that provide personalized user assistance still constitutes a challenge. Mobile application scenarios are diverse and encompass domains like healthcare, logistics, and sales. For their support two fundamental technologies with increasing maturity are emerging: development frameworks for mobile devices and light-weight process engines. Their integrated use, however, is in a rather premature state. Generally, the use of a process engine for supporting mobile collaboration raises many challenging issues. This paper picks up some of these challenges and shows how we have coped with them in the MARPLE project. MARPLE targets at a tight integration of process management technology with mobile computing frameworks in order to enable mobile process support in advanced application scenarios. We give insights into the MARPLE architecture and its components.In particular, we introduce the MARPLE process engine, which enables light-weight as well as flexible process support on mobile devices. This will be key for mobile user assistance in advanced application scenarios

A SOA Repository with Advanced Analysis Capabilities - Improving the Maintenance and Flexibility of Service-Oriented Applications

a service-oriented architecture (SOA), a change or shutdown of a particular service might have a significant impact on its consumers (e.g., IT systems). To effectively cope with such situations, the IT systems affected by a service change should be identified before actually applying the latter. For this purpose, a SOA repository with advanced analysis capabilities is needed. However, due to the numerous complex inter-dependencies between service providers and consumers, it is a challenging task to figure out which IT systems might be directly or indirectly affected by a service change and for which period of time this applies. The paper tackles this challenge and presents the design of an advanced SOA repository enriched with analysis capabilities. In particular, this repository enables automatic analyses to detect already existing problems (as-is analyses) as well as problems that might occur due to future service changes (what-if analyses). Respective analyses will foster the development of robust service-oriented applications

Determining the Quality of Product Data Integration

To meet customer demands, companies must manage numerous variants and versions of their products. Since product-related data (e.g., requirements' specifications, geometric models, and source code, or test cases) are usually scattered over a large number of heterogeneous, autonomous information systems, their integration becomes crucial when developing complex products on one hand and aiming at reduced development costs on the other. In general, product data are created in different stages of the product development process. Furthermore, they should be integrated in a complete and consistent way at certain milestones during process development (e.g., prototype construction). Usually, this data integration process is accomplished manually, which is both costly and error prone. Instead semi-automated product data integration is required meeting the data quality requirements of the various stages during product development. In turn, this necessitates a close monitoring of the progress of the data integration process based on proper metrics. Contemporary approaches solely focus on metrics assessing schema integration, while not measuring the quality and progress of data integration. This paper elicits fundamental requirements relevant in this context. Based on them, we develop appropriate metrics for measuring product data quality and apply them in a case study we conducted at an automotive original equipment manufacturer

Erhöhung der System-Stabilität und -Flexibilität durch ein SOA-Repository mit Analysefähigkeiten

In einer Service-orientierten Architektur (SOA) werden bereitgestellte Services von Servicenutzern, etwa fremden IT-Systemen, konsumiert. Eine Serviceänderung bzw. -abschaltung kann solche Servicenutzer schwer beeinträchtigen. Deshalb müssen diese vor einem solchen Eingriff ermittelt werden, wozu das SOA-Repository genutzt werden kann. Allerdings ist bei umfangreichen SOA-Repositories schwer erkennbar, welche IT-Systeme (evtl. indirekt) in welchem Zeitraum betroffen sein werden. Da diese Problemstellung in der bisherigen SOA-Literatur nicht betrachtet wird, stellen wir ein Lösungskonzept vor. Es ermöglicht automatisierte Analysen, um in den Daten enthaltene Problemsituationen identifizieren zu können (Ist- Analysen), und auch um Auswirkungen zukünftig durchzuführender Serviceänderungen zu simulieren (Planspiele)

Anforderungen an ein Metamodell für SOA-Repositories

Service-orientierte Architekturen (SOA) gewinnen in Unternehmen zunehmend an Bedeutung. Insbesondere die lose Kopplung von Services verspricht mehr Flexibilität. Durch die Vielzahl an Services und Prozessen in unterschiedlichen Varianten sowie deren gleichzeitige Verwendung durch Service-Nutzer, entstehen hohe Kosten für Betrieb und Wartung. Services, die nicht mehr genutzt werden, sollten deshalb zeitnah "abgeschaltet" werden. Um solche nicht mehr benötigten Services identifizieren zu können, muss u.a. bekannt sein, welche Services aktuell von wem benutzt werden. Zudem entstehen durch unterschiedliche Versionen von Services komplexe Abhängigkeiten, die durch eine geeignete Informationsverwaltung im SOA-Repository beherrscht werden müs-sen. Dieser Beitrag stellt die in diesem Zusammenhang bestehenden Anforderungen an ein Metamodell dar

Konzeption eines SOA-Repository mit Analysefähigkeiten

In einer SOA werden bereitgestellte Services von Servicenutzern, etwa fremden IT-Systemen konsumiert. Eine Serviceänderung bzw. -abschaltung kann solche Servicenutzer schwer beein¬trächtigen. Deshalb müssen diese vor einem solchen Eingriff ermittelt werden, wozu das SOA-Repository genutzt werden kann. Allerdings ist bei umfangreichen SOA-Repositories schwer erkennbar, welche IT-Systeme (evtl. indirekt) in welchem Zeitraum betroffen sein werden. Da diese Pro-blem¬stellung in der bisherigen SOA-Literatur nicht betrachtet wird, stellen wir ein Lösungskonzept vor. Es ermöglicht automatisierte Analysen, um in den Daten ent-haltene Problemsituationen zu identifizieren (Ist-Analysen), und auch, um Aus¬wir-kungen zukünftig durchzuführender Serviceänderungen zu simulieren (Planspiele)

Konzeption und Realisierung eines logisch zentralen SOA-Repositories

Service-orientierte Architekturen (SOA) haben sich in den letzten Jahren zum wichtigsten Paradigma etabliert, um IT-Systeme entlang von Geschäftsprozessen auszurichten. Durch die Umsetzung von Funktionalitäten mittels standardisierter Services erhöhen sich Unternehmen mehr Flexibilität, um Änderungen schneller als bisher umzusetzen. Außerdem soll eine SOA die Wiederverwendung von bestehenden Funktionalten in Form von Services ermöglichen, um so Redundanzen und schlieÿlich Kosten für Wartung und Betrieb zu reduzieren. Eine SOA besteht häufig aus einer Vielzahl von Artefakten (etwa Services, Prozesse, Datenobjekte) in unterschiedlichen Versionen. Diese stehen in Beziehungen zueinander, wodurch sich ein komplexes Abhängigkeitsgeecht ergibt. Probleme ergeben sich, wenn z.B. Service-Versionen abgeschaltet oder durch neue Versionen ersetzt werden sollen. Durch die lose Kopplung können Services eine Vielzahl von Service-Konsumenten (Systeme, Prozesse, Applikationen) besitzen. Das Abschalten eines Services kann dazu führen, dass bestehende Service- und Prozessorientierte Applikationen, die diesen Service verwenden, nicht mehr funktionieren, da z.B. der Service-Endpunkt nicht mehr auslösbar ist. Um solche Szenarien zu vermeiden, müssen die Abhängigkeitsbeziehungen in einem zentral logischen SOA-Repository gepegt und verwaltet werden. Weiterere Vorteile einer zentralen Speicherung sind einerseits die Wahrung der Konsistenz und andererseits die Nachvollziehbarkeit im Fall vom Änderungen. Mit Hilfe eines zentral logischen SOA-Repositories sowie darauf aufbauenden Analysen können die Auswirkungen von Änderungen vor der Durchführung ermittelt werden. Ein weiteres Ziel Service-orientierter Architekturen ist die Verbesserung des Business-ITAlignments. Damit ist die Ausrichtung der IT an den Geschäftsprozessen eines Unternehmens gemeint. Die Speicherung von fachlichen und technischen Artefakten alleine ist jedoch nicht ausreichend, um dieses Ziel zu erreichen. Vielmehr wird eine zusätzliche Ebene zwischen fachlichen und technischen Prozessen benötigt, die notwendige Umstrukturierungen zwischen beiden speichert. Diese Ebene wird als Systemprozess bezeichnet und ist integraler Bestandteil der durchgängigen Modellierung von Geschäftsprozessen. Die vorliegende Arbeit liefert ein Metamodell für ein SOA-Repository, welches einerseits die durchgängige Modellierung von Geschäftsprozessen, andererseits Repository-Analysen unterstützt. Mit Hilfe dieser Analysen lassen sich sowohl die Konsistenz über die unterschiedlichen Ebenen einer durchgängigen Modellierung sicherstellen als auch die Auswirkungen von Änderungen vor der Realisierung bestimmen. Um die Repository-Analysen in einer realistischen Umgebung zu veranschaulichen, werden diese exemplarisch durch eine prototypische Implementierung veranschaulicht